A dynamic link library (DLL) is a file that may be loaded and executed by programs dynamically. Basically, a DLL is an external code repository for various programs. Since several different programs typically reuse the same DLL instead of having such code in their own file, the DLL may potentially reduce required storage space by providing a “library” for common use.
Unfortunately, DLL sometimes take unwanted forms. For example, DLLs may include unwanted code in the form of spyware, user-mode root kits, backdoors, etc. which inject unwanted code into application address spaces. This may be accomplished by writing to the application memory remotely, creating a remote thread inside the application address space, etc. As a result, once an application is infected by such a DLL, other applications may also be infected as well.
A browser helper object (BHO) is a component object model (COM) server DLL module designed as a plug-in for the MICROSOFT INTERNET EXPLORER web browser to provide addition functionality. The BHO API exposes hooks that allow the BHO to access the document object model (DOM) of the current page and to control navigation. Because BHOs have unrestricted access to the INTERNET EXPLORER event model, some forms of unwanted code have also been created as BHOs.
For example, the “download.ject” exploit installed a BHO that activated upon detecting a secure HTTP connection to a financial institution, recorded user keystrokes (e.g. intending to capture passwords, etc.), and transmitted the information to a website used by computer criminals. Other BHOs such as the “MyWay Searchbar” tracked users browsing patterns, and passed the recorded information to third-parties.
By way of background, to create an instance of a COM object, a COM client application (which is INTERNET EXPLORER in the BHO case) typically calls the MICROSOFT COM runtime library. Upon handling the COM client application call, the COM runtime library checks first to see if the COM server DLL is loaded in memory or not. If the COM server DLL is not loaded in memory, the COM runtime library calls the WINDOWS loader to load the COM server DLL.
Next, the COM runtime library calls into the COM server DLL to create an instance of the COM server. The COM server DLL returns a pointer to its COM object interface, which is a pointer to an array of pointers to the interface-exported methods. The interface pointer is then returned back to the requesting COM client application through the COM runtime function. As a result, the COM client application (e.g. web browser, etc.) may keep the COM object interface pointer inside associated memory, and call into the COM interface methods via such methods pointers.
In order to effectively repair a BHO that has been subjected to unwanted code, such COM server DLL is freed from the application memory. Based on the way COM objects are instantiated in memory, such BHO may not be easily freed from the application memory after an instance of the BHO COM interface has been created by the application. Specifically, if the BHO DLL is freed from memory, various problems may be unfortunately encountered. For example, an attempt to free the BHO DLL from memory may cause the COM client application to crash upon calling such COM interface methods (since the functions are no longer placed in memory). Further, such attempt may leave a reference count of the COM objects instantiated by the unwanted BHO off by “1,” since the BHO did not release the COM interface before it was unloaded from memory.
There is thus a need for overcoming these and/or other problems associated with the prior art.